Game login method and device

ABSTRACT

This application provides a game login method. The game login method includes receiving a login request sent by a client computing device, where the login request carries a login account; determining at least two groups of corresponding network addresses based on the login account; determining whether the client computing device belongs to a lock region based on lock region configuration corresponding to the login request and the at least two groups of network addresses; and in response to determining that the client computing device does not belong to the lock region, performing login based on the login request.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Chinese Patent Application No.202011302636.3, filed with the China National Intellectual PropertyAdministration on Nov. 19, 2020, and entitled “GAME LOGIN METHOD ANDAPPARATUS”, which is incorporated herein by reference in its entirety.

TECHNICAL FIELD

Embodiments of this application relate to the field of computertechnologies, and in particular, to a game login method. One or moreembodiments of this application simultaneously relate to a game loginapparatus, a computing device, a computer-readable storage medium, and acomputer program product.

BACKGROUND

With rapid development of computer technologies, a growing number ofgames have emerged, which have become indispensable entertainment inlife for most people. When a game is released in different regions, toallow the game to be logged in only in some regions, but not in anotherregion, the game is usually configured with a lock region in which thegame cannot be logged in. Only a client that does not belong to the lockregion can normally log in to the game.

In the conventional technology, a lock region of a game is oftenconfigured in a physical lock or geographical lock manner. Subsequently,when a client requests to log in to the game, a physical lock manner ismainly to perform authentication by using hardware or software code ofthe client, to determine whether the login is allowed; and thegeographical lock manner is mainly to determine a location of the clientthrough Global Positioning System (GPS) positioning, to determinewhether the login is allowed.

However, the physical lock manner relies on preparation of hardware andsoftware resources before a game is released, and is less applicable toa mobile game with a short release cycle and a compact pace. However, inthe geographical lock manner, a user needs to authorize GPS positioning.With increasingly strict personal data protection, for a user who doesnot want to authorize positioning information, a location of a clientcannot be determined. Therefore, when the client requests to log in to agame, verification cannot be performed, resulting in a relatively lowsuccess rate of lock region verification when the client requests to login to the game.

SUMMARY

In view of this, embodiments of this application provide a game loginmethod. One or more embodiments of this application simultaneouslyrelate to a game login apparatus, a computing device, acomputer-readable storage medium, and a computer program product, toresolve a technical defect in the conventional technology that sensitiveinformation of a user is relied on compulsorily, which results in a lowsuccess rate of lock region verification when a client requests to login to a game.

According to a first aspect of the embodiments of this application, agame login method is provided and includes:

-   -   receiving a login request sent by a client, where the login        request carries a login account;    -   obtaining at least two groups of corresponding network addresses        based on the login account;    -   determining, based on lock region configuration corresponding to        the login request and the at least two groups of network        addresses, whether the client belongs to a lock region; and    -   when the client does not belong to the lock region, performing        login based on the login request.

According to a second aspect of the embodiments of this application, agame login apparatus is provided and includes:

-   -   a receiving module, configured to receive a login request sent        by a client, where the login request carries a login account;    -   a first obtaining module, configured to obtain at least two        groups of corresponding network addresses based on the login        account;    -   a first determining module, configured to determine, based on        lock region configuration corresponding to the login request and        the at least two groups of network addresses, whether the client        belongs to a lock region; and    -   a login module, configured to: when the client does not belong        to the lock region, perform login based on the login request.

According to a third aspect of the embodiments of this application, acomputing device is provided and includes:

-   -   a memory and a processor, where    -   the memory is configured to store computer executable        instructions, and the processor is configured to execute the        computer executable instructions to implement the following        method:    -   receiving a login request sent by a client, where the login        request carries a login account;    -   obtaining at least two groups of corresponding network addresses        based on the login account;    -   determining, based on lock region configuration corresponding to        the login request and the at least two groups of network        addresses, whether the client belongs to a lock region; and    -   when the client does not belong to the lock region, performing        login based on the login request.

According to a fourth aspect of the embodiments of this application, acomputer-readable storage medium is provided. The computer-readablestorage medium stores computer executable instructions, and the computerexecutable instructions are executed by a processor to implement thesteps of the game login method.

According to a fifth aspect of the embodiments of this application, acomputer program product is provided. When the computer program productis executed in a computer, the computer is enabled to perform any of thesteps of the foregoing game login method.

According to the game login method provided in the embodiments of thisapplication, the login request sent by the client may be received; thenthe at least two groups of corresponding network addresses are obtainedbased on the login account carried in the login request; it isdetermined, based on the lock region configuration corresponding to thelogin request and the at least two groups of network addresses, whetherthe client belongs to the lock region; and when the client does notbelong to the lock region, login is performed based on the loginrequest. In this case, the lock region configuration may be preset. Whenthe login request is received, it is determined, based on the at leasttwo groups of network addresses corresponding to the login account,whether the client belongs to the lock region corresponding to the loginrequest, so that sensitive information of the user is not relied oncompulsorily, increasing a success rate of lock region verification whenthe client requests to log in to a game. In addition, a developer canlimit a game login region without configuring hardware and software codeof the client in advance, greatly shortening a development cycle of thegame.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a flowchart of a game login method according to an embodimentof this application;

FIG. 2 is a flowchart of lock region verification according to anembodiment of this application;

FIG. 3 is a scenario diagram of a client and a server according to anembodiment of this application;

FIG. 4 is an interaction diagram of a game login method according to anembodiment of this application;

FIG. 5 is a schematic diagram of a structure of a game login apparatusaccording to an embodiment of this application; and

FIG. 6 is a block diagram of a structure of a computing device accordingto an embodiment of this application.

DESCRIPTION OF EMBODIMENTS

Many specific details are described in the following descriptions tofacilitate full understanding of this application. However, thisapplication can be implemented in many different manners from thosedescribed herein. A person skilled in the art may make similar promotionwithout departing from the connotation of this application. Therefore,this application is not limited to the specific implementationsdisclosed below.

Terms used in one or more embodiments of this application are merelyused to describe specific embodiments, but are not intended to limit theone or more embodiments of this application. The terms “a”, “said”, and“the” of singular forms used in one or more embodiments and the appendedclaims of this application are also intended to include plural forms,unless otherwise specified in the context clearly. It should be furtherunderstood that the term “and/or” used in one or more embodiments ofthis application indicates and includes any or all possible combinationsof one or more associated listed items.

It should be understood that although terms such as “first” and “second”can be used in one or more embodiments of this application to describevarious types of information, the information is not limited to theseterms. These terms are only used to differentiate between information ofa same type. For example, without departing from the scope of one ormore embodiments of this application, “first” may also be referred to as“second”, and similarly, “second” may also be referred to as “first”.Depending on the context, for example, the word “if” used herein may beexplained as “while”, “when”, or “in response to determining”.

First, nouns related to one or more embodiments of this application areexplained.

Lock region: Game consoles in a specific region can use a game disc andcassette only in the region. Nowadays, the lock region generally refersto a regional limitation of all games, and can limit a region in which agame can be logged in, or limit a region in which a game cannot belogged in. In embodiments of this application, the lock region definesone or more regions in which a game is not accessible by clientsbelonging to the lock region, that is, a client that belongs to a lockregion of the game cannot log in to the game; and a client that does notbelong to the lock region can log in to the game.

Console game: It is also referred to as a TV game, which includes twoparts: a handheld game and a home console game. The console game is aninteractive multimedia used for entertainment, and usually is a gamethat uses a TV screen as a display to execute a game of a home consoleon a TV.

DLC: is shorted for downloadable content. For a standalone game, the DLCis subsequent downloadable content of the game such as an expansion packand modifications (MOD), which can be considered as additional contentof the game.

In this application, a game login method is provided. This applicationsimultaneously relates to a game login apparatus, a computing device, acomputer-readable storage medium, and a computer program product.Details are described one by one in the following embodiments.

FIG. 1 is a flowchart of a game login method according to an embodimentof this application. The method specifically includes the followingsteps.

Step 102: Receive a login request for logging in to a game sent by aclient computing device, i.e., a client, where the login request carriesa login account.

In actual application, usually, a lock region of a game is mainly putforward by a console game, to ensure that a console game disc orcassette released in a region can be limited to be used only in thereleased region. As a game is released in different regions, users whoplay the game are distributed in different regions. Therefore, there areincreasing demands for a lock region of the game, specific DLC, and aspecific game mission. A conventional lock region is implemented using aphysical lock or a geographical lock. In the physical lock manner,permission authentication is performed mainly by using hardware orsoftware code, and in the geographical lock manner, a location of aclient is determined through GPS positioning, to perform permissionauthentication. However, the physical lock manner relies on preparationof hardware and software resources before a game is released, and isless applicable to a mobile game with a short release cycle and acompact pace. However, in the geographical lock manner, a user needs toauthorize GPS positioning. With increasingly strict personal dataprotection, for a user who does not want to authorize positioninginformation, a location of a client cannot be determined. Therefore,verification cannot be performed when the client requests to log in tothe game.

Therefore, to shorten a development cycle of a game and increase asuccess rate of lock region verification when a client requests to login to a game, the embodiments of this application provide a game loginmethod. The login request sent by the client may be received; then atleast two groups of corresponding network addresses are obtained basedon the login account carried in the login request; it is determined,based on lock region configuration corresponding to the login requestand the at least two groups of network addresses, whether the clientbelongs to the lock region; and when the client does not belong to thelock region, login is performed based on the login request. In this way,it is determined, based on the at least two groups of network addressescorresponding to the login account, whether the client belongs to thelock region corresponding to the login request, so that sensitiveinformation of a user is not relied on compulsorily, and a developer canlimit a game login region without configuring hardware and software codeof the client in advance.

Specifically, the user may operate the client to initiate a loginrequest, to request to log in to a game from a server, and DLC in thegame or a mission in the game. Generally, each user has one loginaccount used to identify an identity of the user. The user may enter thelogin account and a password on the client, and after clicking on“login”, the user may initiate a login request to the server. The loginrequest may carry the login account that needs to be logged in, wherethe login account may be a game identity (ID) of the user.

In an optional implementation of this embodiment, a configurator maypre-access the server and configure a game-related lock region in theserver, that is, before the login request sent by the client isreceived, the method further includes:

-   -   receiving a request of configuring a lock region sent by the        configurator, where the request of configuring the lock region        carries a lock region configuration comprising information        indicating the lock region and a corresponding lock object        associated with a game that is restricted/prohibited from login        by clients in the lock region; and    -   storing the lock region configuration, the corresponding lock        object associated with the game, and a corresponding        relationship between them.

Specifically, the configurator is a game developer who needs to performlock region configuration, and the lock region configuration request isa request triggered by the configurator by using a management device,and is used to pre-configure, in the server, a corresponding lock regionfor the lock region object. The lock region object is content that needsto be locked by the configurator, and the lock region object may be anentire game, or may be a game mission, a plot in a branch line, DLC, orthe like in the game. The lock region configuration is a target regionset for the lock region object, and is used to restrict a client in atarget region from logging in to a corresponding lock region object.

In this embodiment of this application, the configurator may trigger thelock region configuration request to pre-configure, in the server, acorresponding lock region for the lock region object; the configuratormay configure different lock regions for different games, or mayconfigure different lock regions for different game missions, plots indifferent branch lines, or different DLC in a game, that is, mayconfigure a custom lock region of a specific game mission or specificDLC according to needs. In this way, the configurator may determine,according to a requirement of an actual application scenario, whethergranularity of lock region configuration is for an entire game, or forsome content in the game, to achieve higher flexibility in configuring alock region for related content of the game, which can adapt todifferent application scenarios. In addition, the configurator does notneed to modify hardware and software of the client, that is, does notneed to separately make another settings on the lock region, and onlyneeds to senselessly access the server to perform lock regionconfiguration. After the client initiates the login request, the loginrequest may carry corresponding information, and the server performslock region verification based on the information in the login request.

Step 104: Obtain at least two groups of corresponding network addressesbased on the login account.

Specifically, on the basis of receiving the login request sent by theclient, further, the corresponding at least two groups of networkaddresses are obtained based on the login account. The login account canidentify the identity of the user, and therefore the at least two groupsof network addresses when the user logs in to the game can be obtainedbased on the login account.

In an optional implementation of this embodiment, the obtaining at leasttwo groups of corresponding network addresses based on the login accountincludes:

-   -   determining a current login address of the login account; and    -   obtaining, from a historical record, at least one group of        historical network addresses corresponding to the login account,        where each group of historical network addresses includes a        login address and a corresponding reporting heartbeat address.

It should be noted that, each time the user logs in to the game, onelogin address exists, and the server records each login address in thehistorical record. In addition, after the login succeeds, the clientreports a heartbeat to the server in real time, to confirm a connection.Each time the client reports a heartbeat, the server also records areporting heartbeat address. That is, after each login, the historicalrecord stores a current login address and a plurality of correspondingreporting heartbeat addresses. Therefore, each group of historicalnetwork addresses includes one login address and a plurality ofreporting heartbeat addresses corresponding to the login.

In addition, a quantity of groups of historical network addresses thatneed to be obtained may be preset to one group, two groups, or aplurality of groups. A larger quantity of groups of historical networkaddresses indicates more obtained historical network information, sothat accuracy of subsequent lock region verification can be higher.

In a specific implementation, there are a plurality of implementationsof obtaining, from the historical record, at least one group ofhistorical network addresses corresponding to the login account. In apossible implementation, according to a login time axis, historicalnetwork addresses (obtained by using login time as reference) in thehistorical record are sequentially obtained at different time beforecurrent time until a required quantity of groups of historical networkaddresses are obtained. In another possible implementation, a timeperiod between the first login time and current login time is divided,and one group of historical network addresses is randomly obtained ineach time period. Certainly, in an actual implementation, the at leastone group of historical network addresses may be obtained from thehistorical record in another manner. This is not limited in thisembodiment of this application.

For example, the historical network addresses stored in the historicalrecord are shown in the following table 1. It is assumed that time ofreceiving the login request is 11:00 on January 4, in other words,current login time is 11:00 on January 4, a current login address is notrecorded in the historical record because of unsuccessful login thistime. If five groups of historical network addresses need to beobtained, the third group, the fourth group, the fifth group, the sixthgroup, and the seventh group of historical network addresses may besequentially obtained at different time before the current timeaccording to the following table 1.

TABLE 1 Historical network addresses in the historical record Historicalnetwork Reporting address group Login heartbeat Login time identifieraddress address 10:00 on January 1 First group X1 Y1, Y2, Y3 14:00 onJanuary 1 Second group X2 Y4, Y5 20:00 on January 1 Third group X3 Y6,Y7, Y8, Y9 11:00 on January 2 Fourth group X4 Y10, Y11, Y12 16:00 onJanuary 2 Fifth group X5 Y13, Y14 12:00 on January 3 Sixth group X6 Y1519:00 on January 3 Seventh group X7 Y16, Y17, Y18, Y19

In this embodiment of this application, at least two groups of networkaddresses include a login address of the user's login this time, inother words, a current login address, and further include at least onegroup of historical network addresses. Each group of historical networkaddresses may include one login address and a reporting heartbeataddress corresponding to the login, so that it is subsequentlyconvenient to jointly determine, based on the current login address, ahistorical login address, and a corresponding historical reportingheartbeat address, whether the client is located in the lock region, toimprove accuracy of lock region verification when the game is logged in.

In an optional implementation of this embodiment, after the obtaining,from a historical record, at least one group of historical networkaddresses corresponding to the login account, the method furtherincludes:

-   -   determining whether the at least one group of historical network        addresses is valid; and    -   when an invalid historical network address exists in the at        least one group of historical network addresses, deleting the        invalid historical network address; and determining a deleted        quantity of groups of deleted invalid historical network        addresses, and continuing to obtain, from the historical record,        historical network addresses of the deleted quantity of groups.

The determining whether the at least one group of historical networkaddresses is valid may be specifically implemented in the followingprocess:

-   -   for each group of historical network addresses in the at least        one group of historical network addresses, determining whether        the login address and the corresponding reporting heartbeat        address that are in the historical network addresses are in a        same region; and    -   when the login address and the corresponding reporting heartbeat        address are in the same region, determining that the historical        network addresses are valid; or when the login address and the        corresponding reporting heartbeat address are not in the same        region, determining that the historical network addresses are        invalid.

It should be noted that, because each group of historical networkaddresses includes a login address and a corresponding reportingheartbeat address, and when the login address and the correspondingheartbeat reporting address are in a same region, it indicates that theuser does not change a region in a game operation process, and the groupof historical network addresses is valid historical data, which can beused to subsequently determine a lock region. Therefore, after the atleast one group of historical network addresses is obtained, it isnecessary to determine one by one whether each group of obtainedhistorical network addresses is valid. If an invalid historical networkaddress exists, the invalid historical network address may be deleted,and historical network addresses continues to be obtained at previoustime, to ensure that all the obtained historical network addresses arevalid historical network addresses.

The foregoing example is still used. It is assumed that reportingheartbeat addresses and login addresses in the third group and the fifthgroup of historical network addresses belong to different regions, thatis, the third group and the fifth group of historical network addressesare invalid historical network addresses, the obtained third group andthe obtained fifth group of historical network addresses are deleted,and the first group and the second group of historical network addressescontinue to be sequentially obtained at previous time according to theforegoing Table 1.

In this embodiment of this application, after the at least one group ofhistorical network addresses is obtained, an invalid historical networkaddress in the at least one group of historical network addresses may befurther deleted, to ensure validity of the historical network addresses,thereby ensuring accuracy of lock region verification.

In an optional implementation of this embodiment, the login requestfurther carries a client identification code, before the obtaining atleast two groups of corresponding network addresses based on the loginaccount, the method further includes:

-   -   determining whether the client identification code is        identification code in a preset whitelist; and    -   when the client identification code is not the identification        code in the preset whitelist, performing the operation step of        obtaining at least two groups of corresponding network addresses        based on the login account; or    -   when the client identification code is the identification code        in the preset whitelist, determining that the client does not        belong to the lock region.

It should be noted that, in some stages (for example, a game teststage), login permission needs to be opened to a specific client, andthe client with the login permission can perform login regardless ofwhether the client is located in the lock region. Therefore, in thisembodiment of this application, a whitelist may be preset, and thewhitelist stores the client identification code for which login to agame is allowed. After the login request is received, it may be firstdetermined whether the client identification code carried in the loginrequest belongs to the identification code in the preset whitelist. Ifyes, it indicates that the client belongs to a client with the loginpermission, and it is directly determined that the client does notbelong to the lock region, and is allowed for login. That is, for theclient in the whitelist, the lock region is determined without needingto obtain network information again.

Moreover, in addition to the client identification code, the whitelistmay be further set for the login address, that is, a whitelist includinga plurality of login addresses may be preset. After the login request isreceived, it is determined whether a current login address is a loginaddress in the preset whitelist. If no, the operation step of obtainingat least two groups of corresponding network addresses based on thelogin account is performed; or if yes, it is determined that the clientdoes not belong to the lock region.

In this embodiment of this application, the whitelist with the loginpermission may be preset. If it is determined that the client thatinitiates the login request belongs to a client in the whitelist, it maybe directly determined that the client does not belong to the lockregion, and has login permission, improving flexibility of lock regionverification and verification efficiency.

In an optional implementation of this embodiment, before the obtainingat least two groups of corresponding network addresses based on thelogin account, the method further includes:

-   -   determining whether the lock region configuration corresponding        to the login request is pre-stored locally; and    -   if yes, performing the operation step of obtaining at least two        groups of corresponding network addresses based on the login        account; or    -   if no, determining that the client does not belong to the lock        region.

It should be noted that, before lock region verification is performed, atarget object (a game, a game mission, DLC, or the like) to which thelogin request needs to log in may be alternatively determined, and it isdetermined whether the lock region configuration is preset in theserver. If there is no lock region configuration, lock regionverification does not need to be performed; or if there is lock regionconfiguration, the subsequent operation step of lock region verificationneeds to be performed.

In addition, if the whitelist is set in the server, when it isdetermined that the lock region configuration corresponding to the loginrequest is pre-stored locally, the operation step of determining whetherthe client identification code is an identification code in the presetwhitelist may be performed, and then a result is determined based on thewhitelist, to perform subsequent lock region verification.

Step 106: Determine, based on the lock region configurationcorresponding to the game indicated in the login request and the atleast two groups of network addresses, whether the client belongs to thelock region.

Specifically, on the basis of the obtaining at least two groups ofcorresponding network addresses based on the login account, further, itis determined, based on the lock region configuration corresponding tothe login request and the at least two groups of network addresses,whether the client belongs to the lock region. The lock regionconfiguration corresponding to the game indicated in the login requestrefers to a lock region set corresponding to the game comprising a loginobject, i.e., an object to which the login request requests to log in.

Therefore, the login request may further carry information indicative ofthe game comprising the login object. In this way, before thedetermining, based on the lock region configuration corresponding to thelogin request and the at least two groups of network addresses, whetherthe client belongs to the lock region, the lock region configurationcorresponding to the login request may be alternatively obtained firstbased on the login object.

In this embodiment of this application, the configurator may configuredifferent lock regions for different games, or may configure differentlock regions for different game missions, plots in different branchlines, or different DLC in a game, that is, may configure a custom lockregion of a specific game mission or specific DLC according to needs.Therefore, when the login request is received, lock region configurationset for the login object (namely, a lock region object) by theconfigurator is determined based on the login object carried in thelogin request, so that a login region of the login object can besubsequently limited, to implement a regional limitation at a differentgranularity.

In an optional implementation of this embodiment, the determining, basedon the lock region configuration corresponding to the login request andthe at least two groups of network addresses, whether the client belongsto the lock region includes:

-   -   determining whether the at least two groups of historical        network addresses belong to the lock region;    -   counting a first proportion of network addresses that belong to        the lock region and that are in the at least two groups of        network addresses; and    -   when the first proportion is less than or equal to a first        threshold, determining that the client does not belong to the        lock region; when the first proportion is greater than or equal        to a second threshold, determining that the client belongs to        the lock region; or when the first proportion is greater than a        first threshold and less than a second threshold, obtaining        device information of the client, and determining, based on the        device information of the client, whether the client belongs to        the lock region.

It should be noted that the first threshold and the second threshold arepreset values, and are used to determine a quantity of network addressesthat belong to the lock region and that are in the at least two groupsof network addresses. The second threshold is greater than the firstthreshold. If the first proportion of network addresses that belong tothe lock region and that are in the at least two groups of networkaddresses is less than or equal to the first threshold, it indicatesthat most of the obtained network addresses do not belong to the lockregion, and in this case, it may be directly determined that the clientdoes not belong to the lock region; if the first proportion of networkaddresses that belong to the lock region and that are in the at leasttwo groups of network addresses is greater than or equal to the secondthreshold, it indicates that most of the obtained network addressesbelong to the lock region, and in this case, it may be directlydetermined that the client belongs to the lock region; or if the firstproportion of network addresses that belong to the lock region and thatare in the at least two groups of network addresses is greater than thefirst threshold and less than the second threshold, it indicates that apart of the obtained network addresses belong to the lock region, theother part of the obtained network addresses do not belong to the lockregion, and there is no obvious difference between quantities. In thiscase, it cannot be directly determined whether the client belongs to thelock region, and further, it may be determined, based on deviceinformation of the client, whether the client belongs to the lockregion.

The determining, based on the device information of the client, whetherthe client belongs to the lock regions may be specifically implementedin the following process:

-   -   determining whether the device information of the client        includes a device region; and    -   when the device information of the client includes the device        region, if the device region belongs to the lock region,        determining that the client belongs to the lock region; or if        the device region does not belong to the lock region,        determining that the client does not belong to the lock region;        or    -   when the device information of the client does not include the        device region, determining whether the device information of the        client includes language information; and if the device        information of the client includes the language information,        when a language indicated by the language information belongs to        a language corresponding to the lock region, determining that        the client belongs to the lock region, or when a language        indicated by the language information does not belong to a        language corresponding to the lock region, determining that the        client does not belong to the lock region.

It should be noted that the client may request user authorization, toobtain device region information. If the user authorization is obtained,the client can successfully obtain the device region information, and inthis case, the login request initiated by the client may carry thedevice region information for lock region verification; or if the userauthorization is not obtained, the client may not obtain the deviceregion information, but may perform lock region verification based onthe language information of the device. Because a use language isnecessarily set in the client, the client may add language informationof the use language into the login request, so that the server candetermine, based on the language information of the device, a region inwhich the user using the client is located, to determine whether theclient belongs to the lock region. In this way, in a case of informationloss, lock region verification may be performed by using correspondingdegraded logic, to ensure a success rate of lock region verification,thereby ensuring a success rate of game login.

In addition, when the first proportion is less than or equal to thefirst threshold, and the first proportion is greater than or equal tothe second threshold, a further determining step may be alternativelyperformed, and then it is determined whether the client belongs to thelock region. A specific implementation process may be as follows:

-   -   when the first proportion is less than or equal to the first        threshold, if neither of the at least two groups of network        addresses belongs to the lock region, determining that the        client does not belong to the lock region; or if the at least        two groups of network addresses include network addresses that        belong to the lock region, obtaining the device information of        the client, and determining, based on the device information of        the client, whether the client belongs to the lock region; or    -   when the first proportion is greater than or equal to the second        threshold, if a current login address belongs to the lock        region, and at least one group of historical network addresses        belongs to the lock region, determining that the client belongs        to the lock region; if a current login address does not belong        to the lock region, obtaining device information of the client,        and determining, based on the device information of the client,        whether the client belongs to the lock region; or if a current        login address belongs to the lock region, and at least one group        of historical network addresses includes historical network        addresses that do not belong to the lock region, obtaining        device information of the client, and determining, based on the        device information of the client, whether the client belongs to        the lock region.

It should be noted that, in this embodiment of this application, whenneither of the at least two groups of network addresses belongs to thelock region, it may be determined that the client does not belong to thelock region. If the at least two groups of network addresses includenetwork addresses that belong to the lock region, lock regionverification may be further performed based on the device information ofthe client. In addition, when the current login address belongs to thelock region, and the at least one group of historical network addressesbelongs to the lock region, it may be determined that the client belongsto the lock region. Otherwise, lock region verification may be furtherperformed based on the device information of the client, to ensureaccuracy of lock region verification and avoid misjudgment.

FIG. 2 is a flowchart of lock region verification according to anembodiment of this application. With reference to FIG. 2 , the followingdescribes a specific process of lock region verification shown in step102 to step 106 by using an example.

As shown in FIG. 2 , when the login request is received, it isdetermined whether the lock region configuration corresponding to thelogin request is pre-stored locally. If no, it is determined that theclient does not belong to the lock region; or if yes, 10 groups ofnetwork addresses (a current login address and nine groups of historicalnetwork addresses) are obtained, and then it is determined whether thehistorical network addresses are valid. If no, the invalid networkaddresses are deleted, and historical network addresses continue to beobtained at previous time according to a time axis, to supplement thenetwork addresses to be 10 groups, and continue to determine validity ofthe historical network addresses; or if yes, the first proportion ofnetwork addresses that belong to the lock region and that are in the 10groups of network addresses is counted.

When the first proportion is less than (or equal to) 30%, it isdetermined whether none of the groups of network addresses belongs tothe lock region. If yes, it is determined that the client does notbelong to the lock region; or if no, it is determined whether the deviceinformation of the client includes the device region. When the firstproportion is greater than (or equal to 70%), it is determined whetherthe current login address belongs to the lock region. If yes, it isfurther determined whether all the 10 groups of network addresses belongto the lock region, and if yes, it is determined that the client belongsto the lock region, or if no, it is further determined whether thedevice information of the client includes the device region; or if no,it is determined whether the device information of the client includesthe device region.

When the first proportion is greater than 30% and less than 70%, it isdetermined whether the device information of the client includes thedevice region. If yes, it is determined whether the device regionbelongs to the lock region, and if the device region belongs to the lockregion, it is determined that the client belongs to the lock region; orif the device region does not belong to the lock region, it isdetermined that the client does not belong to the lock region. If no, itis determined whether the device information of the client includeslanguage information. If the device information of the client includeslanguage information, it is determined whether a language indicated bythe language information belongs to a language corresponding to the lockregion; and if yes, it is determined that the client belongs to the lockregion, or if no, it is determined that the client does not belong tothe lock region; or if the device information of the client does notinclude the language information, it is determined that the client doesnot belong to the lock region.

Step 108: When the client does not belong to the lock region, performlogin based on the login request.

Specifically, on the basis of the determining, based on the lock regionconfiguration corresponding to the login request and the at least twogroups of network addresses, whether the client belongs to the lockregion, further, when the client does not belong to the lock region,login is performed based on the login request. It should be noted that,if it is determined that the client does not belong to the lock region,it indicates that the client is not in a limited region and can normallylog in to a game. In this case, a corresponding login object may belogged in based on the login request.

In an optional implementation of this embodiment, after the performinglogin based on the login request, the method further includes:

-   -   obtaining a reporting heartbeat address of the client; and    -   recording, in the historical record, a current login address and        the reporting heartbeat address.

It should be noted that, after the game is normally logged in, aheartbeat address reported by the client in real time may be furtherobtained, and a login address and a reporting heartbeat addresscorresponding to the login are recorded in the historical record, toperform lock region verification during subsequent login.

FIG. 3 is a scenario diagram of a client and a server according to anembodiment of this application. As shown in FIG. 3 , a client A1, aclient A2, a client A3, and a client A4 do not belong to the lockregion, so that the client A1, the client A2, the client A3, and theclient A4 can normally establish a connection to the server, and log into the game. However, a client B1, a client B2, and a client B3 belongto the lock region, and cannot log in to the game.

According to the game login method provided in the embodiments of thisapplication, the login request sent by the client may be received; thenthe at least two groups of corresponding network addresses are obtainedbased on the login account carried in the login request; it isdetermined, based on the lock region configuration corresponding to thelogin request and the at least two groups of network addresses, whetherthe client belongs to the lock region; and when the client does notbelong to the lock region, login is performed based on the loginrequest. In addition, the configurator may trigger the lock regionconfiguration request to pre-configure, in the server, a correspondinglock region for the lock region object, so that the configurator canconfigure a custom lock region of a specific game mission or specificDLC according to needs, to achieve higher flexibility in configuring alock region for related content of the game, which can adapt todifferent application scenarios. In addition, the configurator does notneed to modify hardware and software of the client, that is, does notneed to separately make another settings on the lock region, and onlyneeds to senselessly access the server to perform lock regionconfiguration. After the client initiates the login request, the loginrequest may carry corresponding information, and the server performslock region verification based on the information in the login request.Furthermore, during lock region verification, lock region verificationmay be performed based on the network information corresponding to thelogin account and the device information of the client or only based onthe network information, so that sensitive information of the user isnot relied on compulsorily. In a case of information loss, lock regionverification may be performed by using corresponding degraded logic,increasing a success rate of lock region verification when the clientrequests to log in to the game.

FIG. 4 is an interaction diagram of a game login method according to anembodiment of this application. The method specifically includes thefollowing steps:

Step 402: A client requests user authorization, and when the userauthorization is obtained, obtains device information of the client,where the device information includes a device region and languageinformation.

It should be noted that the device region of the client belongs tosensitive information, and therefore user authorization needs to berequested. If the user authorization is obtained, the device region ofthe client may be obtained. In this case, the device informationincludes the device region and the language information. However, a uselanguage is necessarily set in the client, and the language informationof the client does not belong to sensitive information of the user, sothat the client can directly obtain the language information. Therefore,if the user authorization is not obtained, the device region of theclient cannot be obtained. In this case, the device information includesthe language information.

Step 404: The client sends a login request to a serving gateway of aserver, where the login request carries a login account, a clientidentification code, and the device information.

Step 406: The serving gateway of the server parses the login request, toobtain the login account, the client identification code, and the deviceinformation that are carried in the login request.

Step 408: The serving gateway of the server obtains a preset whitelistfrom a database.

Step 410: The serving gateway of the server determines whether theclient identification code carried in the login request is anidentification code in the whitelist.

Step 412: When determining that the client identification code is notthe identification code in the preset whitelist, the serving gateway ofthe server sends a lock region verification instruction to a logincenter of the server.

Step 414: The login center of the server obtains at least two groups ofnetwork addresses corresponding to the login account, and determines,based on the network addresses and the device information, whether theclient belongs to the lock region.

It should be noted that, the step of determining, based on the networkaddresses and the device information, whether the client belongs to thelock region is similar to the specific implementation process ofdetermining whether the client belongs to the lock region in theforegoing embodiment, and reference may be made to related descriptionsin the foregoing embodiment. This is not limited in this application.

Step 416: When the client does not belong to the lock region, the logincenter of the server performs login based on the login account andrecords a login address.

In this embodiment of this application, the whitelist with loginpermission may be preset. If it is determined that the client thatinitiates the login request does not belong to a client in thewhitelist, lock region verification is further performed, to improveflexibility of lock region verification and verification efficiency. Inaddition, the configurator does not need to modify hardware and softwareof the client, that is, does not need to separately make anothersettings on the lock region, and only needs to senselessly access theserver to perform lock region configuration. After the client initiatesthe login request, the login request may carry correspondinginformation, and the server performs lock region verification based onthe information in the login request.

This application further provides a game login apparatus embodimentcorresponding to the foregoing method embodiments. FIG. 5 is a schematicdiagram of a structure of a game login apparatus according to anembodiment of this application. As shown in FIG. 5 , the apparatusincludes:

-   -   a receiving module 502, configured to receive a login request        sent by a client, where the login request carries a login        account;    -   a first obtaining module 504, configured to obtain at least two        groups of corresponding network addresses based on the login        account;    -   a first determining module 506, configured to determine, based        on lock region configuration corresponding to the login request        and the at least two groups of network addresses, whether the        client belongs to a lock region; and    -   a login module 508, configured to: when the client does not        belong to the lock region, perform login based on the login        request.

Optionally, the first obtaining module 504 is further configured to:

-   -   determine a current login address of the login account; and    -   obtain, from a historical record, at least one group of        historical network addresses corresponding to the login account,        where each group of historical network addresses includes a        login address and a corresponding reporting heartbeat address.

Optionally, the first obtaining module 504 is further configured to:

-   -   determine whether the at least one group of historical network        addresses is valid; and    -   when an invalid historical network address exists in the at        least one group of historical network addresses, delete the        invalid historical network address; and determine a deleted        quantity of groups of deleted invalid historical network        addresses, and continue to obtain, from the historical record,        historical network addresses of the deleted quantity of groups.

Optionally, the first obtaining module 504 is further configured to:

-   -   for each group of historical network addresses in the at least        one group of historical network addresses, determine whether the        login address and the corresponding reporting heartbeat address        that are in the historical network addresses are in a same        region; and    -   when the login address and the corresponding reporting heartbeat        address are in a same region, determine that the historical        network addresses are valid; or when the login address and the        corresponding reporting heartbeat address are not in a same        region, determine that the historical network addresses are        invalid.

Optionally, the first determining module 506 is further configured to:

-   -   determine whether the at least two groups of historical network        addresses belong to the lock region;    -   count a first proportion of network addresses that belong to the        lock region and that are in the at least two groups of network        addresses; and    -   when the first proportion is less than or equal to a first        threshold, determine that the client does not belong to the lock        region; when the first proportion is greater than or equal to a        second threshold, determine that the client belongs to the lock        region; or when the first proportion is greater than a first        threshold and less than a second threshold, obtain device        information of the client, and determine, based on the device        information of the client, whether the client belongs to the        lock region.

Optionally, the first determining module 506 is further configured to:

-   -   determine whether the device information of the client includes        a device region; and    -   when the device information of the client includes the device        region, if the device region belongs to the lock region,        determine that the client belongs to the lock region; or if the        device region does not belong to the lock region, determine that        the client does not belong to the lock region; or    -   when the device information of the client does not include the        device region, determine whether the device information of the        client includes language information; and if the device        information of the client includes the language information,        when a language indicated by the language information belongs to        a language corresponding to the lock region, determine that the        client belongs to the lock region, or when a language indicated        by the language information does not belong to a language        corresponding to the lock region, determine that the client does        not belong to the lock region.

Optionally, the login request further carries a client identificationcode, and the apparatus further includes:

-   -   a second determining module, configured to determine whether the        client identification code is an identification code in a preset        whitelist; and when the client identification code is not the        identification code in the preset whitelist, execute the first        obtaining module 504; or when the client identification code is        the identification code in the preset whitelist, determine that        the client does not belong to the lock region.

Optionally, the apparatus further includes:

-   -   a third determining module, configured to determine whether the        lock region configuration corresponding to the login request is        pre-stored locally; and if yes, execute the first obtaining        module 504; or if no, determine that the client does not belong        to the lock region.

Optionally, the apparatus further includes:

-   -   a receiving module, configured to receive a lock region        configuration request sent by a configurator, where the lock        region configuration request carries a lock region object and        lock region configuration; and    -   a storage module, configured to correspondingly store the lock        region object and the lock region configuration.

Optionally, the login request further carries a login object, and theapparatus further includes:

-   -   a second obtaining module, configured to obtain, based on the        login object, the lock region configuration corresponding to the        login request.

Optionally, the apparatus further includes:

-   -   a third obtaining module, configured to obtain a reporting        heartbeat address of the client; and    -   a recording module, configured to record, in the historical        record, a current login address and the reporting heartbeat        address.

According to the game login apparatus provided in this embodiment ofthis application, the configurator may trigger the lock regionconfiguration request to pre-configure, in the server, a correspondinglock region for the lock region object, so that the configurator canconfigure a custom lock region of a specific game mission or specificDLC according to needs, to achieve higher flexibility in configuring alock region for related content of the game, which can adapt todifferent application scenarios. In addition, the configurator does notneed to modify hardware and software of the client, that is, does notneed to separately make another settings on the lock region, and onlyneeds to senselessly access the server to perform lock regionconfiguration. After the client initiates the login request, the loginrequest may carry corresponding information, and the server performslock region verification based on the information in the login request.Furthermore, during lock region verification, lock region verificationmay be performed based on the network information corresponding to thelogin account and the device information of the client or only based onthe network information, so that sensitive information of the user isnot relied on compulsorily. In a case of information loss, lock regionverification may be performed by using corresponding degraded logic,increasing a success rate of lock region verification when the clientrequests to log in to the game.

The foregoing describes the schematic solution of the game loginapparatus in this embodiment. It should be noted that the technicalsolution of the game login apparatus and the technical solution of theforegoing game login method belong to a same concept. For details notdescribed in detail in the technical solution of the game loginapparatus, refer to the descriptions of the technical solution of theforegoing game login method.

FIG. 6 is a block diagram of a structure of a computing device 600according to an embodiment of this application. Components of thecomputing device 600 include but are not limited to a memory 610 and aprocessor 620. The processor 620 and the memory 610 are connected byusing a bus 630, and a database 650 is configured to store data.

The computing device 600 further includes an access device 640. Theaccess device 640 enables the computing device 600 to communicate byusing one or more networks 660. Examples of these networks include apublic switched telephone network (PSTN), a local area network (LAN), awide area network (WAN), a personal area network (PAN), or a combinationof communication networks such as the Internet. The access device 640may include one or more of any type of network interface (for example, anetwork interface card (NIC)) that is wired or wireless, for example, anIEEE802.11 wireless local area network (WLAN) wireless interface, aworldwide interoperability for microwave access (Wi-MAX) interface, anEthernet interface, a universal serial bus (USB) interface, a cellularnetwork interface, a Bluetooth interface, or a near field communication(NFC) interface.

In an embodiment of this application, the foregoing components of thecomputing device 600 and other components not shown in FIG. 6 may bealternatively connected to each other, for example, by using the bus. Itshould be understood that the block diagram of the structure of thecomputing device shown in FIG. 6 is merely used as an example instead ofa limitation on the scope of this application. A person skilled in theart may add or replace other components as required.

The computing device 600 may be any type of still or mobile computingdevice, including: a mobile computer or a mobile computing device (forexample, a tablet computer, a personal digital assistant, a laptopcomputer, a notebook computer, or a netbook), a mobile phone (forexample, a smartphone), a wearable computing device (for example, asmartwatch or smart glasses); another type of mobile device; or a stillcomputing device such as a desktop computer or a PC. The computingdevice 600 may be alternatively a mobile or still server.

The processor 620 is configured to execute the following computerexecutable instructions:

-   -   receiving a login request sent by a client, where the login        request carries a login account;    -   obtaining at least two groups of corresponding network addresses        based on the login account;    -   determining, based on lock region configuration corresponding to        the login request and the at least two groups of network        addresses, whether the client belongs to a lock region; and    -   when the client does not belong to the lock region, performing        login based on the login request.

The foregoing describes the schematic solution of the computing devicein this embodiment. It should be noted that the technical solution ofthe computing device and the technical solution of the foregoing gamelogin method belong to a same concept. For details not described indetail in the technical solution of the computing device, refer to thedescriptions of the technical solution of the foregoing game loginmethod.

An embodiment of this application further provides a computer-readablestorage medium. The computer-readable storage medium stores computerinstructions, and the computer instructions are executed by a processorto implement the steps of the foregoing game login method.

The foregoing describes the schematic solution of the computer-readablestorage medium in this embodiment. It should be noted that the technicalsolution of the storage medium and the technical solution of theforegoing game login method belong to a same concept. For details notdescribed in detail in the technical solution of the storage medium,refer to the descriptions of the technical solution of the foregoinggame login method.

An embodiment of this application further provides a computer programproduct. When the computer program product is executed in a computer,the computer is enabled to perform any of the steps of the foregoinggame login method.

The foregoing describes the schematic solution of the computer programproduct in this embodiment. It should be noted that the technicalsolution of the computer program product and the technical solution ofthe foregoing game login method belong to a same concept. For detailsnot described in detail in the technical solution of the computerprogram product, refer to the descriptions of the technical solution ofthe foregoing game login method.

Specific embodiments of this application are described above. Otherembodiments fall within the scope of the appended claims. In some cases,the actions or steps recorded in the claims can be performed in an orderdifferent from the order in embodiments and the desired results canstill be achieved. In addition, the process depicted in the accompanyingdrawings does not necessarily require the shown particular order orconsecutive order to achieve the desired results. In someimplementations, multi-task processing and parallel processing can ormay be advantageous.

The computer executable instructions include computer program code. Thecomputer program code may be in a source code form, an object code form,an executable file form, an intermediate form, or the like. Thecomputer-readable storage medium may include any entity or apparatus, arecording medium, a USB flash drive, a removable hard disk, a magneticdisk, an optical disc, a computer memory, a read-only memory (ROM), arandom access memory (RAM), an electrical carrier signal, atelecommunications signal, a software distribution medium, and the likethat can carry the computer program code. It should be noted thatcontent included in the computer-readable storage medium may beappropriately added or deleted according to the demands of legislationand patent practice in a jurisdiction, for example, in somejurisdictions, according to legislation and patent practice, thecomputer-readable storage medium includes neither the electrical carriersignal nor the telecommunications signal.

It should be noted that, for ease of description, the foregoing methodembodiments are described as a combination of a series of actions.However, a person skilled in the art should understand that thisapplication is not limited to the described action sequence, becauseaccording to this application, some steps may be performed in anotherorder or simultaneously. In addition, a person skilled in the art shouldalso understand that the embodiments described in this application areall example embodiments, and related actions and modules are notnecessarily mandatory to this application.

In the foregoing embodiments, descriptions of the embodiments haverespective focuses. For a part that is not described in detail in anembodiment, refer to related descriptions in another embodiment.

The example embodiments of this application disclosed above are merelyintended to help describe this application. The optional embodiments donot describe all details, and the present invention is not limited tothe specific implementations. Clearly, many modifications and changesmay be made based on the content of this application. These embodimentsare selected and specifically described in this application to betterexplain the principle and the actual application of this application, sothat a person skilled in the art can better understand and use thisapplication. This application is only subjected to the claims and thescope and equivalents thereof.

1. A game login method, comprising: receiving a login request forlogging into a game sent by a client computing device, wherein the loginrequest carries a login account; determining at least two groups ofcorresponding network addresses based on the login account; determiningwhether the client computing device belongs to a lock region based on alock region configuration corresponding to the game and the at least twogroups of corresponding network addresses, wherein the lock regionindicates one or more regions in which at least a part of the game isnot accessible by client computing devices belonging to the lock region;and in response to determining that the client device does not belong tothe lock region, performing login based on the login request.
 2. Thegame login method according to claim 1, wherein the determining at leasttwo groups of corresponding network addresses based on the login accountcomprises: determining a current login address of the login account; andobtaining, from a historical record, at least one group of historicalnetwork addresses corresponding to the login account, wherein each groupof historical network addresses comprises a login address and acorresponding reporting heartbeat address.
 3. The game login methodaccording to claim 2, wherein the obtaining, from a historical record,at least one group of historical network addresses corresponding to thelogin account further comprises: determining whether the at least onegroup of historical network addresses is valid; in response todetermining that a group of invalid historical network addresses existsin the at least one group of historical network addresses, deleting thegroup of invalid historical network addresses; and determining a numberof groups of invalid historical network addresses that are deleted, andcontinuing to obtain the same number of groups of historical networkaddresses from the historical record.
 4. The game login method accordingto claim 3, wherein the determining whether the at least one group ofhistorical network addresses is valid comprises: determining whether thelogin address and the corresponding reporting heartbeat addresscomprised in each group of historical network addresses are in a sameregion; in response to determining that the login address and thecorresponding reporting heartbeat address are in the same region,determining that a corresponding group of historical network addressesis valid; and in response to determining that the login address and thecorresponding reporting heartbeat address are not in the same region,determining that the corresponding group of historical network addressesis invalid.
 5. The game login method according to claim 1, wherein thedetermining whether the client computing device belongs to a lock regionbased on a lock region configuration corresponding to the game loginrequest and the at least two groups of corresponding network addressescomprises: determining whether each of the at least two groups ofcorresponding network addresses belongs to the lock region; computing afirst proportion of one or more groups of network addresses belonging tothe lock region in the at least two groups of corresponding networkaddresses; and determining that the client computing device does notbelong to the lock region when the first proportion is less than orequal to a first threshold; determining that the client computing devicebelongs to the lock region when the first proportion is greater than orequal to a second threshold; obtaining device information of the clientcomputing device when the first proportion is greater than a firstthreshold and less than a second threshold; and determining whether theclient computing device belongs to the lock region based on the deviceinformation.
 6. The game login method according to claim 5, wherein thedetermining whether the client computing device belongs to the lockregion based on the device information comprises: determining whetherthe device information comprises a device region; when the deviceinformation comprises the device region, determining that the clientcomputing device belongs to the lock region in response to determiningthe device region belongs to the lock region, and determining that theclient computing device does not belong to the lock region in responseto determining that the device region does not belong to the lockregion; when the device information does not comprise the device region,determining whether the device information comprises languageinformation; and when the device information comprises the languageinformation, determining that the client computing device belongs to thelock region in response to determining that a language indicated by thelanguage information belongs to a language corresponding to the lockregion, and determining that the client computing device does not belongto the lock region in response to determining that the languageindicated by the language information does not belong to the languagecorresponding to the lock region.
 7. The game login method according toclaim 1, wherein the login request further carries a clientidentification code associated with the client computing device, andwherein before the determining at least two groups of correspondingnetwork addresses based on the login account, the game login methodfurther comprises: determining whether the client identification code isan identification code in a preset whitelist; in response to determiningthat the client identification code is not in the preset whitelist,performing the determining at least two groups of corresponding networkaddresses based on the login account; and in response to determiningthat the client identification code is in the preset whitelist,determining that the client computing device does not belong to the lockregion.
 8. The game login method according to claim 1, wherein beforethe determining at least two groups of corresponding network addressesbased on the login account, the game login method further comprises:determining whether the lock region configuration is pre-stored locally;and in response to determining that the lock region configuration ispre-stored locally, performing the determining at least two groups ofcorresponding network addresses based on the login account; and inresponse to determining that the lock region configuration is notpre-stored locally, determining that the client computing device doesnot belong to the lock region.
 9. The game login method according toclaim 1, wherein before the receiving a login request for logging into agame sent by a client computing device, the game login method furthercomprises: receiving a request of configuring the lock region sent by aconfigurator, wherein the request of configuring the lock region carriesthe lock region configuration and information indicative of acorresponding lock object associated with the game that is restrictedfrom login; and storing the lock region configuration, the correspondinglock object associated with the game, and a corresponding relationshipbetween them.
 10. The game login method according to claim 1, whereinthe login request further carries information indicative of the gamecomprising an object for login, and wherein before the determiningwhether the client computing device belongs to a lock region based on alock region configuration corresponding to the game and the at least twogroups of corresponding network addresses, the game login method furthercomprises: determining the lock region configuration based on theinformation indicative of the game comprising the object for logincarried in the login request.
 11. The game login method according toclaim 1, wherein after the performing login based on the login request,the game login method further comprises: obtaining a reporting heartbeataddress of the client computing device; and recording, in a historicalrecord, the reporting heartbeat address and a current login address ofthe client computing device.
 12. (canceled)
 13. A computing device,comprising: a memory and a processor, wherein the memory is configuredto store computer executable instructions, and the processor isconfigured to execute the computer executable instructions to implementoperations comprising: receiving a login request for logging into a gamesent by a client computing device, wherein the login request carries alogin account; determining at least two groups of corresponding networkaddresses based on the login account; determining whether the clientcomputing device belongs to a lock region based on a lock regionconfiguration corresponding to the game and the at least two groups ofcorresponding network addresses, wherein the lock region indicates oneor more regions in which at least a part of the game is not accessibleby client computing devices belonging to the lock region; and inresponse to determining that the client device does not belong to thelock region, performing login based on the login request.
 14. Anon-transitory computer-readable storage medium, wherein thecomputer-readable storage medium stores computer instructions, and thecomputer instructions are executable by a processor to implementoperations comprising: receiving a login request for logging into a gamesent by a client computing device, wherein the login request carries alogin account; determining at least two groups of corresponding networkaddresses based on the login account; determining whether the clientcomputing device belongs to a lock region based on a lock regionconfiguration corresponding to the game and the at least two groups ofcorresponding network addresses, wherein the lock region indicates oneor more regions in which at least a part of the game is not accessibleby client computing devices belonging to the lock region; and inresponse to determining that the client device does not belong to thelock region, performing login based on the login request.
 15. (canceled)16. The computing device according to claim 13, wherein the determiningat least two groups of corresponding network addresses based on thelogin account comprises: determining a current login address of thelogin account; and obtaining, from a historical record, at least onegroup of historical network addresses corresponding to the loginaccount, wherein each group of historical network addresses comprises alogin address and a corresponding reporting heartbeat address.
 17. Thecomputing device according to claim 13, wherein the determining whetherthe client computing device belongs to a lock region based on a lockregion configuration corresponding to the game and the at least twogroups of corresponding network addresses comprises: determining whethereach of the at least two groups of corresponding network addressesbelongs to the lock region; computing a first proportion of one or moregroups of network addresses belonging to the lock region in the at leasttwo groups of corresponding network addresses; and determining that theclient computing device does not belong to the lock region when thefirst proportion is less than or equal to a first threshold; determiningthat the client computing device belongs to the lock region when thefirst proportion is greater than or equal to a second threshold;obtaining device information of the client computing device when thefirst proportion is greater than a first threshold and less than asecond threshold; and determining whether the client computing devicebelongs to the lock region based on the device information.
 18. Thecomputing device according to claim 13, wherein before the determiningat least two groups of corresponding network addresses based on thelogin account, the operations further comprise: determining whether thelock region configuration is pre-stored locally; and in response todetermining that the lock region configuration is pre-stored locally,performing the determining at least two groups of corresponding networkaddresses based on the login account; and in response to determiningthat the lock region configuration is not pre-stored locally,determining that the client computing device does not belong to the lockregion.
 19. The computing device according to claim 13, wherein beforethe receiving a login request for logging into a game sent by a clientcomputing device, the operations further comprise: receiving a requestof configuring the lock region sent by a configurator, wherein therequest of configuring the lock region carries the lock regionconfiguration and information indicative of a corresponding lock objectassociated with the game that is restricted from login; and storing thelock region configuration, the corresponding lock object associated withthe game, and a corresponding relationship between them.
 20. Thenon-transitory computer-readable storage medium according to claim 14,wherein the determining at least two groups of corresponding networkaddresses based on the login account comprises: determining a currentlogin address of the login account; and obtaining, from a historicalrecord, at least one group of historical network addresses correspondingto the login account, wherein each group of historical network addressescomprises a login address and a corresponding reporting heartbeataddress.
 21. The non-transitory computer-readable storage mediumaccording to claim 14, wherein before the determining at least twogroups of corresponding network addresses based on the login account,the operations further comprise: determining whether the lock regionconfiguration is pre-stored locally; and in response to determining thatthe lock region configuration is pre-stored locally, performing thedetermining at least two groups of corresponding network addresses basedon the login account; and in response to determining that the lockregion configuration is not pre-stored locally, determining that theclient computing device does not belong to the lock region.
 22. Thenon-transitory computer-readable storage medium according to claim 14,wherein before the receiving a login request for logging into a gamesent by a client computing device, the operations further comprise:receiving a request of configuring the lock region sent by aconfigurator, wherein the request of configuring the lock region carriesthe lock region configuration and information indicative of acorresponding lock object associated with the game that is restrictedfrom login; and storing the lock region configuration, the correspondinglock object associated with the game, and a corresponding relationshipbetween them.